Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-adie-spci-00.txt

Text File | 1993-10-12 | 31.9 KB | 1,371 lines

Internet Draft (SPCI)                              C. Adie
Expires April 1994                    Edinburgh University
Filename draft-adie-spci-00.txt           12 October, 1993


         SGML-based Personal Contact Information (SPCI)



STATUS OF THIS DOCUMENT

This document is an an Internet Draft.  Internet Drafts are
working documents of the Internet Engineering Task Force (IETF),
its Areas and its Working Groups.  (Note that other groups may
also distribute working documents as Internet Drafts.)

Internet Drafts are draft documents valid for a maximum of six
months.  Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time.  It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or as "work in progress".  To learn the
current status of any Internet Draft, please check the 1id-
abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com,
or munnari.oz.au.

SUMMARY

This document describes how personal contact information may be
exchanged in a structured format suitable for machine processing.
The SGML-based Personal Contact Information (SPCI) format can be
used to encode personal information of the type which might be
found on a business card, in a form which is also suitable for
human interpretation.  Possible uses of this format include:
exchange of personal information in email messages; encoding
author information within a document; providing information about
a mailing list; as an exchange format for "address book"
databases; and providing contact information for a company.  The






C. Adie                                                    1


Internet Draft                12 October, 1993 (Expires April
1994)




SPCI information is encoded using SGML, and the specification is
aligned with the SHAVE rules.

A MIME body part type is defined for SPCI information.








































C.Adie             draft-adie-spci-00.txt                  2


Internet Draft                12 October, 1993 (Expires April
1994)




Table of Contents


1. Introduction..........................................4

2. Informal description..................................6

3. SPCI Semantics........................................11
     3.1 SPCI............................................11
     3.2 Person..........................................11
     3.3 EMail...........................................14
     3.4 Location-dependant Contact Information..........15
     3.5 Physical Address................................17

4. MIME Registration.....................................19

5. References............................................20

6. Security Considerations...............................20

7. Acknowlegements.......................................20

8. Contact...............................................21

Appendix I - SPCI Document Type Definition...............22



















C.Adie             draft-adie-spci-00.txt                  3


Internet Draft                12 October, 1993 (Expires April
1994)





1. Introduction

This document defines the SGML-based Personal Contact Information
(SPCI) format.  The purpose of SPCI is as a standard for
exchanging personal information of the type which might be found
on a business card.  It is envisaged that SPCI information will
find a range of applications - some potential applications are
listed below.

. The most common use of SPCI will likely be to provide
  information about the sender of an email message.  SPCI
  information could be supplied in a .signature file,
  automatically appended to mail messages; or it could be sent
  as a separate MIME or X.400 body part.

. SPCI could be used within a document (such as this) to
  indicate the author's contact details.

. SPCI could be used as an exchange format for "address book"
  databases.

. SPCI could be used to convey information about a mailing list,
  rather than about an individual.

. SPCI could be used to convey information about how to contact
  a company, rather than an individual.

In most cases, it is envisaged that the SPCI information will be
typed in by hand, and will be read both by eye and by machine.

SHAVE [Adie 93] defines a set of rules for using SGML to
represent hierarchical attribute/value information in SGML.  This
SPCI specification adheres to those rules by definition.

An SGML document type definition (DTD) for SPCI is defined in
this specification.







C.Adie             draft-adie-spci-00.txt                  4


Internet Draft                12 October, 1993 (Expires April
1994)




The remainder of this document is structured as follows.  Chapter
2 is an informal tutorial description of the SPCI syntax.
Chapter 3 defines the semantics of the SGML elements defined in
the SPCI DTD.  Chapter 4 gives information specific to the MIME
registration of SPCI.  The SPCI DTD itself is given in Appendix
I.






































C.Adie             draft-adie-spci-00.txt                  5


Internet Draft                12 October, 1993 (Expires April
1994)





2. Informal description

This chapter informally describes the syntax of SPCI.  It does
not assume any prior knowlege of SGML on the reader's part.  The
syntax is described through examples, without distinguishing
between the features of SGML, SHAVE and SPCI.  This chapter is
not definitive.

Here is our first example:

<spci>
  <person key="Charles Babbage">
    <name>          Charles Babbage
    </name>
    <title>         Assistant Programmer
    </title>
    <org>           Calculating Machines plc
    </org>
    <email>         [e-mail]
    </email>
  </person>
</spci>

An important SGML concept is the "element" - part of a document
which is delimited by a "start tag" and an "end tag", and which
may contain other elements and plain text.  The main element in
this example has a start tag of <spci> and a corresponding end
tag </spci>.  A program can use these particular tags to identify
where the SPCI information starts and ends.

The spci element contains a person element with its own start and
end tags (we'll ignore the key="Charles Babbage" part for now),
which delimit the information about one particular individual.
You can have more than one person element within an spci element.

The person element contains name, title, org (for organisation)
and email elements, each of which contains plain text data.






C.Adie             draft-adie-spci-00.txt                  6


Internet Draft                12 October, 1993 (Expires April
1994)




There are other elements which could also go in here, as we'll
see.

The tags in the above example have been indented to make the
structure clearer.  You don't have to do this, and in subsequent
examples we often won't bother.  However, note that a tag can't
occur in the middle or at the end of a line - it must occur at
the start (ie before any other non-blank characters).

Having to specify the end tag of every element is unnecessarily
verbose - the end of an element such as title can be indicated by
the start tag of the next element.  In fact, we can omit all the
end tags except for the last:

<spci>
<person key="Horatio Nelson">
<name>         Horatio, Viscount Nelson
<title>        Vice Admiral of the Red
<org>          His Majesty's Navy
<email>        [e-mail]
<email X.400>  /CN=flag/OU=HMS Victory/O=Navy/P=MIL/A= /C=GB
<work>
<phone>        [phone]
  <>           [phone]
<motto>        England expects
               that every man this day
               will do his duty.
</spci>

Note the two occurrances of the email element above.  The first
contains an RFC822 address.  The second email start tag is
qualified by an "SGML attribute" indicating that the contents are
an X.400 email address.  The key="Horatio Nelson" in the person
tag is an example of another SGML attribute.  This key attribute
provides a convenient key which could be used for searching and
indexing purposes by an address book program, for instance.

The motto element shows how the value of a parameter may have
multiple lines.





C.Adie             draft-adie-spci-00.txt                  7


Internet Draft                12 October, 1993 (Expires April
1994)




The work element contains a phone element.  The phone element in
this case represents a parameter with two values, which are
separated by an empty tag <>.

Here's another example, showing some more elements, including an
experimental element X, which in this case contains the name of
the individual's Personal Assistant:

<spci>
 <person key="Olivia Peterson">
  <name>                      Olivia Peterson
  <email>                     [e-mail]
  <title>                     Chairman & Chief Executive
  <org>                       CLIP Inc
  <note>                      Out of the office <16th
  <work>
   <phone>                    [phone]
   <fax>                      [phone]
   <postal>                   456 San Sebastian Avenue, Suite 4629
      <>                      Los Angeles, CA, US
      <>                      94040
   <X type="Personal Assistant">   John Smith
   </X>
  <home>
   <phone>               [phone]  <!-- After 7pm -->
   <fax>                      [phone]
   <instruct>  Operator - notify fax arrival to 234 5678.
  <mobile>
   <phone>                    [phone]
</spci>

Comments are delimited by <!-- and -->, and may occur anywhere on
the line (outside of a tag).  To represent the less than
character "<" in the value of a parameter, you use the four-
character string <, and to represent the ampersand "&" you use
&.  No other characters need escaping in SPCI.

Here is a highly artificial example, which shows almost all the
tags and almost all the features of the SPCI format.





C.Adie             draft-adie-spci-00.txt                  8


Internet Draft                12 October, 1993 (Expires April
1994)




<spci>
<person key="John Jones">

<name>         Dr John J. Jones
<title>        Consulting Physicist
<dept>         External contracts department
<org>          High Energy Physics Clearances Inc
<email>        [e-mail]
<email X.400>  /I=J/S=Jones/O=HEPC/P=Fargle/A= /C=US
<note>         Ignore any error messages for the X.400 address
<X.500>        J. Jones, High Energy Physics Clearances Inc, US
<motto>        Let us clear those old, unwanted Feynman
               diagrams out of your office.  Green's functions
               also accepted.

<work>
<phone>        [phone]
  <>           [phone] <!-- Secretary -->
<fax>          [phone]
  <>           [phone]
<room>         2309
<building>     Higgs Boson Building
<street>       321 Main St
<city>         Los Angeles
<state>        CA
<postcode>     12345
<country>      USA
<telex>        456789012

<home>
<phone>        [phone]
<fax>
<faxno>        [phone] <!-- Auto fax/voice switch -->
<faxno>        [phone]
<instruct>     Operator - please call 765 4321
               and notify fax arrival
<postal>       12 Leafy Avenue
  <>           Croyden
  <>           LONDON





C.Adie             draft-adie-spci-00.txt                  9


Internet Draft                12 October, 1993 (Expires April
1994)




               SW9 9XX
               Great Britain
<courier>
<carrier>      TNT
<phone>        [phone]

<mobile>
<phone>        [phone]
<pager>
<phone>        [phone]
<instruct>     Ask for page number 3456789
<fax>          [phone] <!-- In the car -->
</spci>

Here is an example of a mailing list represented in SPCI:

<spci>
<person key="MMIS list">
<name>              Multimedia Information Systems mailing list
<email list>        [e-mail]
<email listownr>    [e-mail]
<note>              This is the mailing list of the RARE
                    Multimedia Information Systems Task
                    Force.
</spci>



















C.Adie             draft-adie-spci-00.txt                 10


Internet Draft                12 October, 1993 (Expires April
1994)





3. SPCI Semantics

The DTD for SPCI is given in Appendix I.  The remainder of this
chapter describes the semantics of the elements defined in the
DTD.  Extracts from the DTD are included in the text for ease of
reference, but in the event of a disagreement between the text
and the DTD in Appendix I, the latter takes priority.

The SPCI DTD conforms to the SHAVE rules for DTDs specified in
[Adie 93].  SPCI documents must comply with the SHAVE rules for
document instances also defined therein.


3.1 SPCI

<!ELEMENT spci - -  (person*) >

All SPCI data is enclosed within an spci element, which must have
both a start tag and an end tag.  An SPCI element may contain
zero, one or more person elements.

The purpose of the spci element is to delimit SPCI information
within some larger text object such as a mail message or
document.  Note that if SPCI information is sent as a body part
in a MIME message, the MIME message structure could be regarded
as delimiting the SPCI information - however the spci start and
end tags must still be present.

There may be more than one spci element within a text object such
as a file or mail message.


3.2 Person

<!ELEMENT person    - O  (name? & email* & title? & org? &
                         dept? & motto? & note? & X.500? &
                         work? & home? & mobile? & support?
                         & picture?) +(X) >





C.Adie             draft-adie-spci-00.txt                 11


Internet Draft                12 October, 1993 (Expires April
1994)




The basic element of SPCI is the person element.  A person
element may contain zero or one of each of the following types of
element, in any order: name, X.500, title, org, dept, motto,
note, work, home, mobile, support, picture.  It may contain any
number of email elements which must all be adjacent.
Experimental X elements may be present anywhere within a person
element and its included elements.

The start tag of a person element is mandatory, but the end tag
is not.  The end of a person element is also indicated by a start
tag of the next person, or by an spci end tag.

<!ATTLIST person key     CDATA     #REQUIRED>

A person element has one (mandatory) SGML attribute, key.  The
key takes a value (enclosed in double quotes) which may be used
for indexing purposes.  The key should be the person's name, but
omitting any prefixes (eg Dr, Professor) and suffixes (eg Jr,
BSc), in order to facilitate sorting and searching.  Note that an
application such as an address book program may modify or ignore
the key it reads from a received document.  One reason for doing
this might be that the application already has an entry in its
database which uses that key.

The elements which may be contained in a person element are as
follows:

name      Personal name of an individual, with prefixes and
          suffixes if desired.

title     The role of the individual within the organisation for
          which s/he works.

org       The name of the organisation for which the individual
          works.

dept      The department (or other sub-unit) of the organisation
          within which the individual works.






C.Adie             draft-adie-spci-00.txt                 12


Internet Draft                12 October, 1993 (Expires April
1994)




motto     Descriptive text associated with the individual,
          workgroup or organisation.

note      Information which does not fit elsewhere.

email     Electronic mail address of the individual.  There may
          be more than one such element, but they must all be
          located together.  See the following section.

work      See the section on Location-dependent Contact
          Information below.

home      See the section on Location-dependent Contact
          Information below.

mobile    See the section on Location-dependent Contact
          Information below.

support   A list of the supported MIME types, each type in the
          standard MIME format of the type/subtype, and each such
          pair separated by a list separator <>.  Note that the
          list of MIME types may not be relevant for non-RFC822
          email addresses.

X.500     The Directory Name of the individual, in UFN form (see
          RFCxxxx).  If the program which reads the SPCI is
          capable of looking up the Directory, any attributes
          found therein override their SPCI equivalents.

picture   A photograph of an individual may make it easier to
          establish contact - eg when meeting someone at an
          airport.  The contents of this element is a URL which
          points to an image of the individual.  The element has
          a mandatory attribute encoding, which contains the MIME
          type and subtype of the image file.  The MIME type will
          usually be "image".








C.Adie             draft-adie-spci-00.txt                 13


Internet Draft                12 October, 1993 (Expires April
1994)





3.3 EMail

<!ELEMENT email     - O  (#PCDATA) >
<!ATTLIST email
     mailsys   (X.400|RFC822)           RFC822
     mailtype  (person|list|listownr)   person
>

The email element can occur more than once in a person element.
It contains an electronic mail address of some kind.  The email
element has two SGML attributes, which may both be defaulted.

The mailsys SGML attribute can take one of the following values:
X.400, RFC822.  If no value is specified, RFC822 is assumed.  If
the value of mailsys is X.400, the contents of the element is an
X.400 O/R Address, expressed in textual form according to CCITT
recommendation F.4xx.  If the value of mailsys is RFC822, the
contents of the element is an email address as specified in
RFC822.

The mailtype attribute can take one of the following values:
person, list, listownr.  If no value is specified, person is
assumed.  The meaning of these values is as follows:

person    The email address is the address of an individual.

list      The email address is the submission address of a
          mailing list.

listownr  The email address is the administration address for a
          mailing list (for subscription requests, address
          changes etc).

The latter two are intended for use when the enclosing person
element describes a mailing list rather than an individual.








C.Adie             draft-adie-spci-00.txt                 14


Internet Draft                12 October, 1993 (Expires April
1994)





3.4 Location-dependant Contact Information

An email address is generally independant of the actual physical
location at any particular instant of the individual being
addressed - you could for instance read your email either from
home or at work.  However, this is not generally true of other
forms of communication such as telephone, fax or postal services.
Therefore, within a person element, there can be any combination
of a work element, a home element and a mobile element,
specifying contact information specific to an individual's
location.

<!ELEMENT work - O  (phone? & fax? & telex? & ((%physadr;),courier?)?)
>
<!ELEMENT home - O  (phone? & fax? & telex? & ((%physadr;),courier?)?)
>
<!ELEMENT mobile    - O  (phone? & fax? & pager?) >

A work element may contain (a list of) phone numbers, (a list of)
fax numbers and associated details, a telex address, and a
physical address suitable for use by a postal service.  Any
combination of these components may be present, in any order.  A
home element may contain the same elements as work..  A mobile
element may contain phone and fax information, and pager details
as well.

<!ELEMENT phone     - O  (item+)>

The phone element may thus occur in several places.  Its content
is one or more voice phone numbers, conforming to CCITT
recommendation F.103.  Phone numbers are separated by the usual
list separator characters <>, per the SHAVE rules.  The order of
phone numbers in the list is significant - the first number in
the list should be tried first, and if it is engaged or there is
no answer, subsequent numbers should be tried in order.








C.Adie             draft-adie-spci-00.txt                 15


Internet Draft                12 October, 1993 (Expires April
1994)




<!ELEMENT fax   - O (faxno)+ >
<!ELEMENT faxno      O O (#PCDATA,(grain? & instruct? &
faxgate?)) >
<!ELEMENT instruct - O   (#PCDATA) >
<!ELEMENT grain      - O (#PCDATA) >
<!ELEMENT faxgate    - O (#PCDATA) >

The fax element is a bit more complex.  It is a list of one or
more faxno elements, each of which consists of #PCDATA
(representing the fax number itself, confirming to CCITT F.103),
followed by any combination of the following three elements:

grain     The grain of the fax machine - may have the values
          regular or fine only.

instruct  Handling instructions for facsimile operator.

faxgate   Internet address of gateway to the facsimile service.

The order of fax numbers in the list is significant - the first
number in the list should be tried first, and if it is engaged or
there is no answer, subsequent numbers should be tried in order.

<!ELEMENT telex     - O  (#PCDATA)>

A telex element contains the telex number to contact.

<!ELEMENT pager     - O  (phone, instruct?)>

A pager element must contain a phone element with the number to
call to arrange for the individual to be paged.  It may also
contain an instruct element, containing further details of how to
page.











C.Adie             draft-adie-spci-00.txt                 16


Internet Draft                12 October, 1993 (Expires April
1994)





3.5 Physical Address

<!ENTITY % physadr
"postal|(room?,building?,street?,restante?,pobox?,
      city?,ponumber?,state?,postcode?,country?)" >

A physical address could be used for delivery of a physical
object such as a letter or parcel, by a postal or courier
service.  There are two ways in which a physical address can be
encoded in SPCI.  One method or the other must be selected - they
cannot be mixed.

The first way uses the postal element.  The contents of this is a
list of address items, separated by the normal list separator <>.
Each item in the list represents one line of address information
which might appear on an envelope.  The order of items in the
list is significant - the first item in the list appears at the
top of the address, and the last appears at the bottom.  The last
line will often (but not always) be the country name.

The second way of encoding a physical address uses individual
elements for each component of the address.  Each element may
occur zero or once, and the elements must be in the following
order:

room      The room within a building for delivery.

building  The name of the building.

street    Street address (name and number).

restante  Post restante address.

pobox     Post office box number.

city      Town or city.

ponumber  Post Office number.





C.Adie             draft-adie-spci-00.txt                 17


Internet Draft                12 October, 1993 (Expires April
1994)




state     District, region, province or state.

postcode  Postal or ZIP code.

country   Country name (in full - ISO3166 abbreviations are not
          normally acceptable except where they are in very
          common use - eg "USA").

Following a physical address (in either form), there may be a
courier element, specifying a preferred courier service for
delivery to the address.

<!ELEMENT courier   - O  (carrier, account?, delivery?, phone?) >

The courier element may contain the following elements, in the
order given below.

carrier   Name of the courier organisation.  Mandatory in a
          courier element.

account   Account reference number.

delivery  Copied from PCI.  What is this for?

phone     Phone number of recipient (many courier companies
          require this information).


















C.Adie             draft-adie-spci-00.txt                 18


Internet Draft                12 October, 1993 (Expires April
1994)





4. MIME Registration

The MIME registration for SPCI will be as follows:

MIME type name:     TEXT

MIME subtype name:  SPCI

Required parameters:     none

Optional parameters:     none

Encoding considerations: Some characters may not be sent directly
               through some transport services.  Where possible,
               it is recommended that quoted-printable encoding
               be used, to preserve readability.

Security considerations: See separate section.

Published specification: A TEXT/SPCI body part will comprise
               exactly one spci element as defined in this
               specification.

Rationale:     Provides human-readable and machine-processable
               method of encoding personal contact information.
               This will permit automated processing, such as for
               maintaining personal files of contact information.

Contact information:     See separate section.














C.Adie             draft-adie-spci-00.txt                 19


Internet Draft                12 October, 1993 (Expires April
1994)





5. References

[Adie 93] SGML-based Hierarchical Attribute/Value Encoding
          (SHAVE), C. Adie, September 1993.  Internet Draft (work
          in progress).

[Crocker 93a]  Structured Text Interchange Format (STIF), D.
          Crocker, June 1993.  Internet Draft (work in progress).

[Crocker 93b]  Encoding for Personal Contact Information (PCI),
          D. Crocker, June 1993.  Internet Draft (work in
          progress).


6. Security Considerations

This document specifies a format for encoding personal contact
information.  It does not address issues relating to the accuracy
or authenticity of the information so encoded.

Individuals who supply contact information are invited to
consider whether the disclosure of such information (eg home
address) might lead to undesired consequences.


7. Acknowlegements

SPCI was inspired by Dave Crocker's work on STIF [Crocker 93a]
and PCI [Crocker 93b], and the semantics of the SPCI elements are
based on those specifications.

If you provide constructive comments, you could find your name
appearing here.










C.Adie             draft-adie-spci-00.txt                 20


Internet Draft                12 October, 1993 (Expires April
1994)





8. Contact

<spci>
 <person key="Chris Adie">
  <name>       Chris Adie
  <dept>       Computing Service
  <org>        Edinburgh University
  <email>      [e-mail]
  <work>
   <phone>     [phone]
   <fax>       [phone]
   <building>  University Library Building
   <street>    George Square
   <city>      Edinburgh
   <postcode>  EH8 9LJ
   <country>   Great Britain
</spci>


























C.Adie             draft-adie-spci-00.txt                 21


Internet Draft                12 October, 1993 (Expires April
1994)





Appendix I - SPCI Document Type Definition

<!DOCTYPE spci [

<!-- Entity declarations -->
<!ENTITY amp     "&" >
<!ENTITY lt      "<" >
<!ENTITY % INHERIT  "#IMPLIED" >
<!ENTITY % aglobal  "cset CDATA %INHERIT;" >

<!-- This is used in the content models of elements which are lists. -
->
<!ELEMENT item   O O (#PCDATA) >
<!ATTLIST item   %aglobal; >

<!-- The notation used for external references by this specification.
-->
<!NOTATION url   SYSTEM>

<!-- For experimental use. -->
<!ELEMENT X      - O RCDATA >
<!ATTLIST X
        %aglobal;
        type     CDATA     #REQUIRED
>

<!-- All SPCI data must be inside an spci element -->
<!ELEMENT spci   - - (person*) >
<!ATTLIST spci   %aglobal; >

<!-- Top-level element is a person -->
<!ELEMENT person - O (name? & email* & title? & org? & dept? &
                     motto? & note? & X.500? & work? & home? &
                     mobile? & support? & picture?) +(X) >
<!ATTLIST person
        %aglobal;
        -- for indexing purposes --
        key      CDATA     #REQUIRED





C.Adie             draft-adie-spci-00.txt                 22


Internet Draft                12 October, 1993 (Expires April
1994)




>

<!ELEMENT name   - O (#PCDATA) -- Personal name -->
<!ATTLIST name   %aglobal; >

<!ELEMENT org    - O (#PCDATA) -- Organisation -->
<!ATTLIST org    %aglobal; >

<!ELEMENT title  - O (#PCDATA) -- Role within org -->
<!ATTLIST title  %aglobal; >

<!ELEMENT dept   - O (#PCDATA) -- Department within org -->
<!ATTLIST dept   %aglobal; >

<!ELEMENT motto  - O (#PCDATA) -- Your text goes here -->
<!ATTLIST motto  %aglobal; >

<!ELEMENT X.500  - O (#PCDATA) -- Directory Name in UFN form -->
<!ATTLIST X.500  %aglobal; >

<!ELEMENT support- O (item+)   -- List of supported MIME types -->
<!ATTLIST support%aglobal; >

<!ELEMENT note   - O (#PCDATA) -- Info which doesn't fit elsewhere --
>
<!ATTLIST note   %aglobal; >

<!ELEMENT picture- O (#PCDATA) -- Photo of the individual -->
<!ATTLIST picture
        %aglobal;
        type     NOTATION  (url) url -- Content points to image --
        encoding CDATA     #REQUIRED -- MIME type/sybtype --
>

<!ELEMENT email  - O (#PCDATA) -- Electronic mail address -->
<!ATTLIST email
        %aglobal;
        mailsys  (X.400|RFC822) RFC822 -- any others? --
        mailtype (person|list|listownr) person





C.Adie             draft-adie-spci-00.txt                 23


Internet Draft                12 October, 1993 (Expires April
1994)




>

<!-- A physical address can either be an (unformatted) postal address,
     or a sequence of attributes. -->
<!ENTITY % physadr "postal|(room?,building?,street?,restante?,pobox?,
city?,ponumber?,state?,postcode?,country?)" >

<!-- These containers delimit contact info for different environments
-->
<!ELEMENT work   - O (phone? & fax? & ((%physadr;),courier?)? &
telex?) >
<!ATTLIST work   %aglobal; >

<!ELEMENT home   - O (phone? & fax? & ((%physadr;),courier?)? &
telex?) >
<!ATTLIST home   %aglobal; >

<!ELEMENT mobile - O (phone? & fax? & pager?) >
<!ATTLIST mobile %aglobal; >

<!ELEMENT phone  - O (item+)  -- may be more than one phone number --
>
<!ATTLIST phone  %aglobal; >

<!ELEMENT pager  - O (phone, instruct?) >
<!ATTLIST pager  %aglobal; >

<!ELEMENT telex  - O (#PCDATA) >
<!ATTLIST telex  %aglobal; >

<!-- Fax information is provided in several fax elements -->
<!ELEMENT fax    - O (faxno)+ >
<!ATTLIST fax    %aglobal; >

<!ELEMENT faxno  O O (#PCDATA,(grain? & instruct? & faxgate?)) >
<!ATTLIST faxno  %aglobal; >

<!ELEMENT instruct  - O
     (#PCDATA) >





C.Adie             draft-adie-spci-00.txt                 24


Internet Draft                12 October, 1993 (Expires April
1994)




<!ATTLIST instruct  %aglobal; >

<!ELEMENT grain  - O (#PCDATA) >
<!ATTLIST grain  %aglobal; >

<!ELEMENT faxgate- O (#PCDATA) >
<!ATTLIST faxgate%aglobal; >

<!-- A physical address as a (list of) undistinguished text items. -->
<!ELEMENT postal - O (item+) >
<!ATTLIST postal %aglobal; >

<!-- A physical address separated into its individual elements -->
<!ELEMENT room   - O (#PCDATA) -- Room within a building -->
<!ATTLIST room   %aglobal; >

<!ELEMENT building  - O
     (#PCDATA) -- Name of building -->
<!ATTLIST building  %aglobal; >

<!ELEMENT street - O (#PCDATA) -- Street address -->
<!ATTLIST street %aglobal; >

<!ELEMENT restante  - O
     (#PCDATA) -- Post restante address -->
<!ATTLIST restante  %aglobal; >

<!ELEMENT pobox  - O (#PCDATA) -- Post Office Box number -->
<!ATTLIST pobox  %aglobal; >

<!ELEMENT city   - O (#PCDATA) -- Town or city -->
<!ATTLIST city   %aglobal; >

<!ELEMENT ponumber  - O
     (#PCDATA) -- Post Office number -->
<!ATTLIST ponumber  %aglobal; >

<!ELEMENT state  - O (#PCDATA) -- District, region or state -->
<!ATTLIST state  %aglobal; >





C.Adie             draft-adie-spci-00.txt                 25


Internet Draft                12 October, 1993 (Expires April
1994)





<!ELEMENT postcode  - O
     (#PCDATA) -- Postal or zip code -->
<!ATTLIST postcode  %aglobal; >

<!ELEMENT country- O (#PCDATA) -- Country -->
<!ATTLIST country%aglobal; >

<!-- Courier delivery information -->
<!ELEMENT courier- O (carrier, account?, delivery?, phone?) >
<!ATTLIST courier%aglobal; >

<!ELEMENT carrier- O (#PCDATA) >
<!ATTLIST carrier%aglobal; >

<!ELEMENT account- O (#PCDATA) >
<!ATTLIST account%aglobal; >

<!ELEMENT delivery  - O
     (#PCDATA) >
<!ATTLIST delivery  %aglobal; >

]>





















C.Adie             draft-adie-spci-00.txt                 26